Понятие зрелости процессов создания ПО. Модель оценки зрелости СММ

Проблема.

Организации, работающие в области разработки, поставки, внедрения и сопровождения ПО и системной интеграции, все больше ощущают, что в основе их конкурентоспособности лежат качество и низкий уровень себестоимости, технологичность производства.

Руководители таких организаций не всегда могут сформировать стратегию совершенствования и развития технологии деятельности своей компании; на рынке труда специалистов необходимой квалификации явно недостаточно. Вместе с тем в области совершенствования технологических процессов разработки и эксплуатации ПО международный опыт долгие годы был недостаточно обобщен и формализован. Только в начале 1990-х годов американский Институт программной инженерии (SEI) сформировал модель технологической зрелости организаций СММ (Capability Maturity Model), определив уровни технологической зрелости и их отличительные черты. В течение десятилетия СММ прошла апробацию в целом ряде организаций, ее эффективность и достоверность проверили заказывающие организации, поставщики ПО, компании, осуществляющие разработку заказного ПО, занимающиеся оффшорным программированием.

Сегодня на западе компания-разработчик практически испытывает большие трудности с получением заказов, если она не аттестована по СММ. Заказчики требуют гарантий технологичности компании-исполнителя, гарантий того, что исполнитель не может оказать некачественную услугу.

Оценка технологической зрелости компаний может использоваться:

• заказчиком при отборе лучших исполнителей (например, в тендере);

• компаниями-производителями ПО для систематической оценки состояния своих технологических процессов и выбора направлений их совершенствования;

• компаниями, решившими пройти аттестацию, для оценки «размеров бедствия», т.е. своего текущего состояния;

• аудиторами для определения стандартной процедуры аттестации и проведения необходимых оценок;

• консалтинговыми фирмами, занимающимися реструктуризацией компаний и служб поставщиков информационных технологий и связанных с ними услуг.

По мере повышения технологической зрелости организации процессы создания и сопровождения ПО становятся более стандартизованными и согласованными. При этом формализация процессов позволяет стандартизовать ожидаемые результаты их выполнения и обеспечить предсказуемость результатов выполнения проектов.

Зрелость процессов (software process maturity) — это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации. Реальное использование процессов невозможно без их документирования и доведения до сведения персонала организации, без постоянного контроля и совершенствования их выполнения. Возможности хорошо продуманных процессов полностью определены. Повышение технологической зрелости процессов означает, что эффективность и качество результатов их выполнения могут постоянно возрастать.

В организациях, достигших технологической зрелости, процессы создания и сопровождения ПО принимают статус стандарта, фиксируются в организационных структурах и определяют производственную тактику и стратегию. Введение их в статус закона влечет за собой необходимость построения необходимой инфраструктуры и создания требуемой корпоративной культуры производства, которые обеспечивают поддержку соответствующих методов, операций и процедур ведения дел даже после того, как из организации уйдут те, кто все это создал.

Решение

Модель СММ развивает положения о системе качества организации, формируя критерии ее совершенства — пять уровней технологической зрелости, которые в принципе могут быть достигнуты организацией-разработчиком. Наивысшие — четвертый и пятый уровни — это фактически характеристика организаций, овладевших методами коллективной разработки, в которых процессы создания и сопровождения ПО комплексно автоматизированы и поддерживаются технологически.

Начиная с 1990 г. SEI (Институт программной инженерии) при поддержке правительственных структур США и организаций-разработчиков ПО постоянно развивает и совершенствует эту модель, учитывая все новейшие достижения в области создания и сопровождения ПО.

Назначение состав и характеристика модели CMM

СММ представляет собой методический материал, определяющий правила формирования системы управления созданием и сопровождением ПО и методы постепенного и непрерывного повышения культуры производства. Назначение СММ — предоставление организациям-разработчикам необходимых инструкций по выбору стратегии повышения качества процессов путем анализа степени их технологической зрелости и факторов, в наибольшей степени влияющих на качество выпускаемой продукции. Фокусируя внимание на небольшом количестве наиболее критичных операций и планомерно повышая эффективность и качество их выполнения, организация, таким образом, может добиться неуклонного постоянного повышения культуры создания и сопровождения ПО.

СММ — это описательная модель в том смысле, что она описывает существенные (или ключевые) атрибуты, которые определяют, на каком уровне технологической зрелости находится организация. Это нормативная модель в том смысле, что детальное описание методик устанавливает уровень организации, необходимый для выполнения проектов различной сложности и продолжительности по контрактам с правительственными структурами США. СММ не является предписанием, она не предписывает организации, каким образом развиваться. СММ описывает характеристики организации для каждого из уровней технологической зрелости, не давая каких-либо инструкций как переходить с уровня на уровень. Организации может потребоваться несколько лет для перехода с первого на второй уровень и совсем мало времени для перехода с уровня на уровень далее. Процесс совершенствования технологии создания ПО отражается в стратегических планах организации, ее структуре, используемых технологиях, общей социальной культуре и системе управления.

На каждом уровне устанавливаются требования, при выполнении которых достигается стабилизация наиболее существенных показателей процессов. Выход на каждый уровень технологической зрелости является результатом появления определенного количества компонентов в процессах создания ПО, что в свою очередь приводит к повышению их производительности и качества. На рисунке 1 показаны пять уровней технологической зрелости СММ. Надписи на стрелках определяют особенности совершенствования процессов при переходе с уровня на уровень.

Рисунок 1 - Пять уровней технологической зрелости СММ

Уровни со второго по пятый могут характеризоваться через операции, направленные на стандартизацию и (или) модернизацию процессов создания ПО, и через операции, составляющие сами процессы его создания. При этом первый уровень является как бы базой, фундаментом для сравнительного анализа верхних уровней.

На уровне 1 (начальном) основные процессы создания и сопровождения ПО носят случайный характер и выполняются хаотично. Успех выполнения проекта всецело зависит от индивидуальных усилий персонала. На этом уровне, как правило, в организации не существует стабильной среды, необходимой для создания и сопровождения ПО.

Успех проекта при этом, как правило, полностью зависит от степени энергичности и опыта руководства и профессионального уровня исполнителей. Может случиться, что энергичный руководитель преодолеет все препятствия в процессе выполнения проекта и добьется выпуска действительно жизнеспособного программного продукта. Но после того, как такой руководитель оставит свой пост, исчезнет и гарантия того, что следующий подобный проект будет успешным. При отсутствии необходимого уровня управления проектом положение не сумеет спасти даже передовая технология.

Процессы на первом уровне характеризуются своей непредсказуемостью в связи с тем, что их состав, назначение и последовательность в процессе выполнения проекта меняются случайным образом в зависимости от текущей ситуации. Вследствие этого перерасходуются выделенные средства и срываются графики работ. Подготовка способных и знающих специалистов в организациях является основной из предпосылок успеха на всех уровнях зрелости, но на первом уровне это единственная возможность добиться хоть каких-либо положительных результатов.

На уровне 2 (уровне повторяемых процессов) процессы управления проектом позволяют обеспечивать текущий контроль стоимости проекта, графика его выполнения и выполняемых функций. Дисциплина выполнения проекта такова, что существует возможность прогнозирования успешности выполнения проектов по созданию аналогичных программных продуктов.

На этом уровне планирование проектных работ и управление новыми проектами базируется на опыте успешно выполненных аналогичных проектов. Основной особенностью второго уровня является наличие формализованных и документированных эффективных процессов управления проектами, что позволяет использовать положительный опыт успешно завершенных проектов. Эффективными могут называться процессы, которые документированы, реально используются, поддаются количественной оценке и пригодны для модернизации. Необходимо, чтобы персонал был обучен их применению.

Каждый уровень СММ, начиная со второго, характеризуется наличием ряда так называемых основных групп процессов (key process areas - КРА). Модель СММ содержит 18 таких групп, последняя версия модели CMMI — 20 групп. Уровень 2 СММ характеризуется наличием в организации следующих процессов (их наименования соответствуют CMMI):

• управление требованиями;

• управление конфигурацией;

• планирование проекта;

• мониторинг и контроль проекта;

• управление контрактами;

• измерения и анализ;

• обеспечение качества процесса и продукта.

Процессы на втором уровне можно охарактеризовать как упорядоченные в связи с тем, что они заранее планируются, и их выполнение строго контролируется, за счет чего достигается предсказуемость результатов выполнения проекта. С увеличением и усложнением проектов внимание смещается с технических аспектов их выполнения на организационные и управленческие аспекты. Выполнение процессов требует от персонала более эффективной и слаженной работы, что, в свою очередь, требует изучения документированного передового опыта в целях повышения профессионального мастерства.

На уровне 3 (уровне стандартизованных процессов) процессы создания ПО документированы, стандартизованы и представляют собой единую технологическую систему, обязательную для всех подразделений организации. Во всех проектах используется опробованная, утвержденная и возведенная в статус стандарта единая технология создания и сопровождения ПО.

На данном уровне к процессам уровня 2 добавляются следующие процессы:

• спецификация требований;

• интеграция продукта;

• верификация;

• аттестация;

• стандартизация процессов организации;

• обучение;

• интегрированное управление проектом;

• управление рисками;

• анализ и принятие решений.

Основным критерием использования и, при необходимости, корректировки процессов на этом уровне является помощь звену управления и техническим специалистам в повышении эффективности выполнения проектов. На этом уровне в организации создается специальная группа, ответственная за состав операций, из которых состоят процессы, — группа по разработке процессов создания ПО (software engineering process group — SEPG).

На основе единой технологии для каждого проекта могут разрабатываться свои процессы с учетом его особенностей. Такие процессы в СММ называются «проектно-ориентированные процессы создания ПО» (project's defined software process).

Описание каждого процесса включает в себя условия его выполнения, входные данные, стандарты и процедуры выполнения, механизмы проверки (например, экспертные оценки), выходные данные и условия завершения. В описание процесса также включаются сведения об инструментальных средствах, необходимых для его выполнения, и указание на роль, ответственную за его выполнение.

Главное назначение уровня 4 (уровня управляемых процессов) — текущий контроль над процессами. Управление должно обеспечивать выполнение процессов в рамках заданного качества. Могут быть неизбежные потери и временные пики в измеряемых результатах, которые требуют вмешательства, но в целом система должна быть стабильна.

На уровне 4 добавляются следующие процессы:

• управление производительностью и продуктивностью;

• количественное управление проектом.

На этом уровне, на практике применяется детальная оценка качества, как процессов создания, так и самого создаваемого программного продукта. При этом применяются количественные критерии оценки.

В рамках всей организации разрабатывается единая программа количественного контроля производительности создания ПО и его качества. Для облегчения анализа процессов создается единая база данных процессов создания и сопровождения ПО для всех проектов, выполняемых в организации. Разрабатываются универсальные методики количественной оценки производительности процессов и качества их выполнения. Это позволяет проводить количественный анализ и оценку процессов создания и сопровождения ПО.

Результаты выполнения процессов на четвертом уровне становятся предсказуемы, поскольку они измеряемы и варьируются в рамках заданных количественных ограничений. На этом уровне появляется возможность заранее планировать заданное качество выполнения процессов и конечной продукции.

Основное назначение уровня 5 (уровня оптимизируемых процессов) — последовательное усовершенствование и модернизация процессов создания и сопровождения ПО. В целях плановой модернизации технологии создания ПО в организации создается специальное подразделение, основными обязанностями которого являются сбор данных по выполнению процессов, их анализ, модернизация имеющихся и создание новых процессов, их проверка на пилотных проектах и придание им статуса стандартов предприятия.

На уровне 5 добавляются следующие процессы:

• внедрение технологических и организационных инноваций;

• причинно-следственный анализ и разрешение проблем.

Процессы создания и сопровождения ПО характеризуются как последовательно совершенствуемые, поскольку организация прилагает постоянные усилия по их модернизации. Это совершенствование распространяется как на выявление дополнительных возможностей используемых процессов, так и на создание новых оптимальных процессов и использование новых технологий.

Нововведения, которые могут принести наибольшую выгоду, стандартизуются и адаптируются в технологическую систему в рамках всей организации. Персонал, принимающий участие в выполнении проекта, анализирует дефекты и выявляет причины их возникновения. Процессы создания ПО оцениваются в целях предотвращения повторения ситуаций, приводящих к дефектам, а результаты оценки учитываются в последующих проектах.

Каждый последующий уровень дополнительно обеспечивает более полную обозримость самих процессов создания и сопровождения ПО.

На первом уровне процессы являются аморфными («черными ящиками»), и их обозримость весьма ограничена. С самого начала состав и назначение операций практически не определены, что порождает значительные трудности в определении состояния проекта и его продвижения. Требования по выполнению процессов задаются бесконтрольно. Разработка ПО в глазах менеджеров (особенно тех, кто сам не является программистом) иногда выглядит как черная магия.

На втором уровне выполнение требований пользователя и создание ПО контролируемы, поскольку определена база для процессов управления проектом. Процесс создания ПО может рассматриваться как последовательность «черных ящиков», которые можно контролировать в точках перехода из одного «ящика» в другой — зафиксированных этапах. Даже если руководитель не знает, что делается «внутри ящика», точно установлено, что должно получиться в результате выполнения процесса, и определены контрольные точки его начала и завершения. Поэтому управление может распознавать проблемы в точках взаимодействия «черных ящиков» и своевременно на них реагировать.

На третьем уровне определена внутренняя структура «черных ящиков», т.е. задачи, из которых состоят процессы. Внутренняя структура представляет собой путь, по которому стандартные процессы в организации применяются в конкретных проектах. Звено управления и исполнители в необходимой степени детализации знают свои роли и ответственность в рамках проекта. Руководство заранее подготовлено к рискам, которые могут возникнуть в процессе выполнения проекта. Так как стандартизированные и документированные процессы становятся «прозрачными» для обозрения, сотрудники, непосредственно не занятые в проекте, могут своевременно получать точные сведения о его текущем состоянии.

На четвертом уровне выполнение процессов жестко привязывается к инструментальным средствам, что дает возможность определения количественных характеристик их трудоемкости и качества выполнения. Руководители, имея объективную базу количественных измерений, получают возможность точного планирования стадий и этапов выполнения проекта, прогнозирования продвижения проекта, и могут своевременно и адекватно реагировать на возникающие проблемы. С уменьшением возможных отклонений от заданных сроков, стоимости и качества в процессе выполнения проекта их возможность предвидения результатов постоянно возрастает.

На пятом уровне в целях повышения качества продукции и повышения эффективности ее создания постоянно и планомерно проводится работа по созданию новых усовершенствованных методов и технологий создания ПО. Внимание обращается при этом не только на уже используемые, но и на новые более эффективные процессы и технологии. Руководители могут количественно оценивать влияние и эффективность изменений в технологии создания и сопровождения ПО.

Четвертый и пятый уровни редко встречаются в индустрии ПО. Так, если третьего уровня достигло в мире несколько сотен компаний, то фирм пятого уровня (по информации SEI на 2002 г.) насчитывалось 62, а четвертого - 72. При этом отметим, что объявляют о своем уровне зрелости далеко не все компании. Одни не заинтересованы в афишировании своих организационных технологий, другие выполняют сертификацию просто под давлением заказчика.

Для достижения высших уровней СММ требуется десять и более лет. Но даже уровень 3 позволяет смело выходить на международную арену. Для использования СММ компании не надо искать сотрудников с какими-то уникальными способностями, ей достаточно понять общую идею. В описании модели СММ детально указано, что надо делать, чтобы развиваться в соответствии с этой моделью. Следовать регламентированным действиям СММ способен любой менеджер среднего класса.

Последняя версия СММ 1.1 в основном ориентирована на крупные компании, занимающиеся реализацией больших проектов, но она вполне может использоваться и группами из двух-трех человек или отдельными программистами для выполнения небольших проектов (продолжительностью до трех месяцев). В таких случаях модель СММ может сыграть жизненно важную роль, поскольку поступление новых заказов во многом определяется качеством реализации предыдущих проектов. Маленькие группы вполне удовлетворятся уровнем 2, так как для небольшого проекта отклонение от срока на пару недель непринципиально.

С 2002 г. официально распространяется специальная интеграционная версия CMMI. Это новая разработка SEI, охватывающая все аспекты деятельности компании: от разработки и выбора подрядчика до обучения, внедрения и сопровождения. Кроме того, модель CMMI расширена подходами из системной инженерии. В эту модель вошли наработки, сделанные в ходе проектирования версии СММ 2.0 (она не была закончена), основные изменения в которой были направлены на уточнение процессов для компаний четвертого и пятого уровней, что наиболее актуально для крупномасштабных американских проектов.

Модель СММ достаточно весома и важна, однако не стоит применять ее как единственную основу, определяющую весь процесс создания ПО. Она была предназначена в основном для компаний, которые занимаются разработкой ПО для Министерства обороны США. Эти системы отличаются большими размерами и длительным сроком эксплуатации, а также сложностью интерфейса с аппаратным обеспечением и другими системами ПО. Над созданием таких систем работают достаточно большие коллективы программистов, которые должны подчиняться требованиям и стандартам, разработанным Министерством обороны. К недостаткам СММ относятся следующие:

1. Модель сосредоточена исключительно на управлении проектом, а не на процессе создания программного продукта. В модели не учтены такие важные факторы, как использование определенных методов, например прототипирования, формальных и структурных методов, средств статического анализа и т.п.

2. В модели отсутствует анализ рисков и решений, что не позволяет обнаруживать проблемы прежде, чем они окажут воздействие на процесс разработки.

3. Не определена область применения модели, хотя авторы признают, что она является универсальной и подходящей всем организациям. Однако авторы не дают четкого разграничения организаций, которые могут или не могут внедрять СММ в свою деятельность. Небольшие компании находят эту модель слишком бюрократичной. В ответ на эту критику были разработаны стратегии совершенствования технологического процесса для малых организаций.

Главной целью создания модели СММ было намерение Министерства обороны США оценить возможности поставщиков ПО. На данный момент пока не существует четких требований к достижению определенного уровня развития организаций-разработчиков. Однако принято считать, что у организации, достигшей высокого уровня, больше шансов выиграть тендер на поставку ПО.

Альтернатива СММ

В качестве альтернативы СММ предлагается обобщенная классификация процессов совершенствования технологической зрелости, которая подходит для большинства организаций и программных проектов . Можно выделить несколько общих типов процессов совершенствования.

1. Неформальный процесс. Не имеет четко выраженной модели совершенствования. Его с успехом может использовать отдельная команда разработчиков. Неформальность процесса не исключает таких формальных действий, как управление конфигурацией, однако при этом сами действия и их взаимосвязи не предопределены заранее.

2. Управляемый процесс. Имеет подготовленную модель, которая управляет процессом совершенствования. Модель определяет действия, их график и взаимосвязи между ними.

3. Методически обоснованный процесс. Подразумевается, что введены в действие определенные методы (например, систематически применяются методы объектно-ориентированного проектирования). Для процессов этого типа будут полезными инструментальные средства поддержки проектирования и анализа процессов (CASE-средства).

4. Процесс непосредственного совершенствования. Имеет четко поставленную цель совершенствования технологического процесса, для чего существует отдельная строка в бюджете организации и определены нормы и процедуры внедрения нововведений. Частью такого процесса является количественный анализ процесса совершенствования.

Эту классификацию не назовешь четкой и исчерпывающей — некоторые процессы могут одновременно относиться к нескольким типам. Например, неформальность процесса является выбором команды разработчиков. Эта же команда может выбрать определенную методику разработки, имея при этом все возможности непосредственного совершенствования процесса. Такой процесс подпадает под классификацию неформальный, методически обоснованный, непосредственного совершенствования.

Необходимость приведенной классификации обусловлена тем, что она предоставляет основу для комплексного совершенствования технологии создания ПО и дает возможность организации выбирать разные типы процессов совершенствования. На рис. 1.8 показаны соотношения между разными типами программных систем и процессами совершенствования их разработки.

Рисунок 2 - Применимость процессов совершенствования

Знание типа разрабатываемого продукта сделает соответствие между программными системами и процессами совершенствования, показанное на рисунке 2, полезным при выборе процесса совершенствования. Например, требуется создать программу поддержки перехода ПО с одной компьютерной платформы на другую. Такая программа имеет достаточно короткий срок эксплуатации, поэтому в ее разработке не требуются стандарты и специальное управление процессом совершенствования, как при создании долгоживущих систем.

Многие технологические процессы в настоящее время имеют CASE-средства поддержки, поэтому их можно назвать поддерживаемыми процессами. Методически обоснованные процессы поддерживаются инструментальными средствами анализа и проектирования. Эффективность средства поддержки зависит от применяемого процесса совершенствования. Например, в неформальном процессе могут использоваться типовые средства поддержки (средства прототипирования, компиляторы, средства отладки, текстовые процессоры и т.п.). Вряд ли в неформальных процессах будут использоваться на постоянной основе более специализированные средства поддержки.

Модель СММ не уникальна. Почти каждая крупная компания развивает собственные технологии создания ПО, иногда эти технологии становятся общедоступными и очень популярными. Широкая известность модели СММ связана с ее государственной поддержкой, но реальная эффективность СММ критикуется многими ведущими экспертами. Один из основных недостатков СММ связан с излишне жестким требованием не отклоняться от принципов данной модели, даже если здравый смысл подсказывает обратное. Подобные претензии на владение абсолютной истиной не могут не вызвать настороженности, поэтому в среде малых и средних компаний более популярны подходы, оставляющие гораздо больше свободы для индивидуального и коллективного творчества. Рассматриваемая далее методика SPMN занимает промежуточное место между жесткими, «тяжелыми», эффективными для крупных организаций решениями типа СММ и максимально гибкими технологиями. Она представляется оптимальным вариантом для фирм, которые, с одной стороны, хотят как можно быстрее упорядочить свою управленческую деятельность, а с другой стороны, планируют в перспективе выйти на международный уровень, где сертификация по СММ крайне желательна.

Методика SPMN

Большинство современных технологий разработки ПО основаны на принципе улучшения процесса разработки, когда наибольшую свободу действий в выборе способа реализации имеет руководитель проекта. В то же время признанные мировые лидеры, создающие качественное ПО (их единицы во всем мире), активно используют принцип лучшего практического навыка. Этот принцип ориентирован на улучшение деталей работы и быстрое достижение конечного результата. В нем нет абстрактного «улучшения процесса», а есть конкретные рекомендации, использующие числовые характеристики проекта. Другое преимущество принципа лучших практических навыков - возможность их немедленного применения в противовес «тяжелой» модели СММ, для сертификации по которой нужны годы труда. Несмотря на определенное число очень успешных результатов внедрения СММ, эта методика не получила массового признания среди небольших фирм в силу сложности и слишком больших усилий, требуемых для ее внедрения. Продолжающиеся неудачи в крупных программных проектах заставили Министерство обороны США сформировать подразделение SPMN (Software Program Managers Network), которое было призвано помочь военным быстро наладить эффективные процессы управления проектами в организациях-разработчиках ПО.

Эксперты Министерства обороны, выполнив масштабную работу по анализу хода различных проектов, представили руководству министерства заключение, в котором, в частности, говорилось: «Существующие методы разработки ПО в Министерстве обороны США не создают необходимых условий для управления крупномасштабными проектами по созданию ПО, которое является неотъемлемой частью комплексных боевых систем».

На основе этого заключения для SPMN были определены четыре главные цели ее работы.

1. Внедрить в Министерстве обороны лучшие практические навыки создания ПО.

2. Позволить руководителям проектов сфокусировать свои усилия на разработке качественного ПО, а не на следовании должностным инструкциям и формальным методикам, которые только ухудшали состояние проекта.

3. Позволить руководителям проектов использовать лучшие мировые практические навыки с учетом локальной корпоративной культуры.

4. Дать возможность быстро изучить и внедрить эти навыки в свою работу с помощью соответствующих методик обучения и программных систем.

В SPMN было создано три подразделения.

1. Группа оперативных советов определила важнейшие практические навыки (всего их набралось девять). В выявлении лучших навыков участвовали такие общепризнанные эксперты, как Гради Буч, Эдвард Йордон и др. В дополнение к лучшим навыкам они разработали технологию Панели управления ходом программного проекта (Software Project Control Panel), описывающую ключевые индикаторы состояния проекта. Были также определены важнейшие цели типичного проекта, способы их количественной оценки и границы допустимых состояний. Составлен справочник ответов на вопросы, часто задаваемые руководителям проектов, и выделен набор самых плохих практик.

2. Группа периодических обновлений, состоящая из 180 специалистов по программной инженерии, которые обработали 163 методики 56 компаний и выделили 43 лучших практических навыка, расширивших и дополнивших 9 ключевых навыков.

3. Группа управления, контролирующая работу двух предыдущих групп и определяющая способы ее улучшения.

Подход, предложенный отделом SPMN, называется СВР (Critical Best Practices, критически важные практические навыки). Он позволяет тактическими изменениями в работе организации очень быстро (за полтора—два года) примерно на 80% достичь третьего уровня СММ (на что обычно требуется около десяти лет). При этом подход СВР проверен на сотнях реальных крупных программных проектов.

Рекомендации по применению практических навыков достаточно очевидны. В самом общем виде подход СВР предлагает:

• сфокусироваться на количественных параметрах завершения проекта (дате, бюджете, объеме);

• придумать быстро реализуемую стратегию выполнения проекта;

• измерять продвижение к цели;

• измерять активность разработки.

Результаты работы SPMN показали, что ход выполнения крупных проектов обычно находится на грани хаоса, и существует ряд факторов, от которых зависит, перейдет ли система в неуправляемое состояние. Чтобы правильно управлять проектом, надо придерживаться следующих принципов.

1. Ошибки и логические неувязки надо выявлять как можно раньше и устранять сразу после обнаружения. Между внесением ошибки разработчиком и ее выявлением должно пройти минимальное время (в проектах Министерства обороны США среднее время между внесением ошибки и ее устранением составляло 9 месяцев). Практика почасовой оплаты программистов (имевшая место при выполнении госзаказов в США) совершенно недопустима. Надо также совершенствовать механизмы выявления типичных причин ошибок и способы их устранения.

2. Необходимо планировать работу на основе правильно выбранных показателей. Невозможно реализовать крупный проект, если не подготовить в его рамках максимально подробный план всех видов деятельности с учетом производительности сотрудников, объема проекта, бюджета и других ресурсов.

3. Надо минимизировать неконтролируемые изменения проекта с учетом того, что они вносятся разработчиками на всех этапах, начиная с требований к системе и заканчивая ее пользовательскими интерфейсами.

4. Необходимо эффективно использовать сотрудников. Знания, опыт и мотивация сотрудников - важнейшие факторы успеха. Акцент в управлении проектами должен быть смещен на производительность труда, качество работы, выполнение планов и удовлетворение пользователя. Для этого требуются большие усилия по подготовке профессиональных руководителей проектов и изменения текущих способов их подготовки.

Девять лучших навыков, рекомендованных SPMN

Каждый из описываемых далее навыков полезен сам по себе, но их совместное использование значительно повышает общую эффективность. Немаловажно, что эти навыки могут быть внедрены без дополнительных расходов на оборудование, технологии и персонал.

Навык 1 - формальное управление рисками. Любой проект по разработке ПО - рискованный. Но отсутствие процедуры управления рисками в компании - это, пожалуй, самый показательный признак грядущей неудачи проекта. Поэтому необходимо уметь определять риск превышения бюджета и времени выполнения, неверного выбора и возможного отказа оборудования, ошибок программирования и плохого сопровождения. Риск оценивается по вероятности возникновения и его последствиям.

Надо смягчать последствия рисков путем их раннего выявления и максимально ранней ликвидации, профилактической работы и изменения курса проекта «в обход» потенциальных неудач. Неустраненные риски надо отслеживать по параметрам «стоимость последствий риска» и «стоимость устранения риска». Желательно создавать резервные запасы ресурсов для устранения непредвиденных проблем.

В рамках проекта рекомендуется постоянно вести и анализировать списки 10 важнейших рисков; списки неустраненных рисков в наиболее критических точках проекта; отчеты по устраненным, неустраненным и новым рискам; учитывать возможную стоимость последствий рисков в зависимости от имеющегося резерва. SPMN советует также использовать анонимные каналы для получения информации от персонала о неизвестных «подводных камнях» в проекте, чтобы в коллективе не создавалась атмосфера замалчивания ошибочных действий (типичная рекомендация для американской корпоративной культуры). Одновременно надо «декриминализировать» сам риск. У сотрудников не должно быть никаких иллюзий о допустимости рисков, при этом необходимо понять, что каждый выявленный риск - это предупрежденный риск.

Навык 2 - соглашения об интерфейсах: пользовательских, внутренних (межмодульных) и внешних (для стыковки с другими компонентами и приложениями).

Интерфейсы программы — это необходимая часть системных требований и ее архитектуры, но руководители проектов часто забывают контролировать соответствие продукта этим соглашениям. Чем позже будут определены соглашения об интерфейсах, тем больше вероятность того, что систему придется заново проектировать, программировать и тестировать.

Для построения пользовательского интерфейса неплохо использовать подход RAD. При этом пользовательский интерфейс (как и все остальные) надо полностью определить, согласовать с заказчиком и утвердить до начала этапов проектирования и разработки. Его описание должно быть включено в системную спецификацию на уровне определения каждого экранного поля, элемента ввода/вывода и средств навигации между формами/окнами/экранами.

Правильность интерфейса проверяет и утверждает только реальный пользователь каждого рабочего места из организации-заказчика. Для встраиваемой системы готовятся отдельные требования к ее внешнему интерфейсу.

Навык 3 - формальные проверки проекта. Нередко устранение ошибок начинается, только когда проект переходит к этапу тестирования. Такие этапы были придуманы 30 лет назад для создания небольших по сегодняшним меркам систем, и хотя в тестировании нет ничего плохого, выделять его в отдельный этап методически неверно. Стоимость этапа тестирования может достигать 40-60% стоимости всего проекта. Эти ненужные усилия можно сократить на порядок, однако немногие руководители знают, как это сделать.

Существует немало стандартных подходов раннего выявления ошибок, позволяющих обнаруживать 80% ошибок в момент их внесения, или многократные просмотры кода (выявляется 60% ошибок). Чтобы оперативно обнаружить 90-100% ошибок, надо использовать несколько подходов. Ведущие компании одновременно применяют 10 и более методик формальных проверок (анализ структуры проекта, проверки кода, редактирование документации, множественное тестирование и т. п.).

Не менее важны усилия по проверке корректности проекта на этапах формулирования требований, создания архитектуры системы и проектирования. Для выполнения формальных проверок надо использовать небольшие группы сотрудников с четко определенными ролями, привлекая при этом пользователей организации-заказчика. Персонал необходимо постоянно тренировать в умении анализировать код на наличие ошибок. Желательно отслеживать продолжительность усилий по проверкам проекта, число найденных ошибок по отношению к затраченным на их поиск усилиям и среднее время от внесения ошибки до ее устранения.

Навык 4 — управление проектом на основе метрик. Этот навык нужен для раннего обнаружения потенциальных проблем. Как уже говорилось, стоимость устранения дефекта в проекте увеличивается в геометрической прогрессии по мере роста проекта.

С помощью метрик (числовых характеристик) планируются все задачи проекта. Ход их выполнения надо регулярно отслеживать, как минимум, - по ключевым показателям (стоимость работы и производительность труда). Надо дополнительно контролировать время, затрачиваемое на устранение дефектов, и следить за важнейшими показателями, чтобы по их отклонениям (в любую сторону — например, слишком резвый старт) выявлять потенциальные «подводные камни». Метрики основываются на эмпирических данных, например, на основе результатов анализа схожих по размерам проектов.

Навык 5 - качество продукта должно контролироваться на глубоком уровне. Проблема реализации мелких деталей программного проекта очень важна при разработке ПО. Иногда мелкое на первый взгляд требование заказчика выливается в глобальную переделку проекта. Если же проект спланирован недостаточно подробно, обсуждать реальное положение дел в ходе его выполнения бессмысленно.

В проекте надо выделить задачи объемом не более 5% по продолжительности и усилиям, которые могут быть выполнены отдельной группой сотрудников как минимум на 95%. Каждая подобная задача должна быть ориентирована на выполнение однотипной работы. Результат выполнения задачи оценивается группой приемки, при этом работа не может быть принята с оговорками: она должна быть выполнена полностью и без ошибок (двоичная система оценки качества «готово/не готово»).

Навык 6 — информация о ходе проекта должна быть общедоступной. Чем больше сотрудников вовлечено в процесс контроля над ходом проекта, тем проще идентифицировать потенциальные проблемы и риски. Надо сделать показатели хода проекта доступными всем сотрудникам и заказчику и организовать канал приема анонимных сообщений о возникающих проблемах. Чаще всего такой канал используется для сведения личных счетов, но лучше получить ложный сигнал, чем не узнать о реальной проблеме. К тому же открытость проекта — это залог снижения числа ложных сообщений.

Навык 7 - чтобы добиться высокого качества, надо отслеживать причины возникновения ошибок. Эффективность работы компании непосредственно зависит от наличия ошибок в проекте. Большинство компаний не контролируют их реальные источники: ошибки программистов, отклонения в графиках выполнения работ, превышение планируемой стоимости, неверно сформулированные требования, неправильно подготовленную документацию и плохо обученный персонал. В каждой фазе проекта ошибки должны отслеживаться формально. Для этого желательно использовать средства конфигурационного управления. Каждый случай обнаружения и устранения ошибки обязательно надо документировать.

Устранять ошибки необходимо по мере их возникновения. При этом учет ошибок удобнее всего вести в нормализованном виде (в расчете на единицу объема, например, на тысячу строк кода). Согласно принципу «снежного кома», с ростом объема проекта норма ошибок в нем увеличивается. Также надо контролировать среднее и максимальное время устранения ошибки и время от внесения до устранения ошибки в течение каждого этапа проекта и на протяжении первого года эксплуатации системы.

Навык 8 — управление конфигурацией. Неконтролируемые изменения в проекте могут быстро ввергнуть его в хаос. Поэтому на практике надо руководствоваться двумя простыми правилами:

• любую информацию, которую использует более чем один сотрудник, надо контролировать с помощью системы управления конфигурацией;

• любую информацию, учитываемую системой качества, надо контролировать с помощью системы управления конфигурацией.

Надо отслеживать все изменения в состоянии создаваемой системы, бюджете и сроках, интерфейсах, контрольных отчетах и т. п. Без систем управления конфигурацией при этом не обойтись, потому что в крупном проекте большие объемы информации меняются очень быстро. Каждый учитываемый объект должен определяться его версией, при этом надо вести архив всех версий всех таких объектов.

Навык 9 — управление персоналом. Главный фактор успеха проекта — качество, опыт и мотивация сотрудников. Не надо забывать, что с помощью различных методик производительность труда программистов можно значительно повысить. К тому же, как бы подробно ни документировался проект, некоторые детали его архитектуры всегда хранятся только в головах разработчиков, и руководитель проекта должен помогать сотрудникам проявлять индивидуальные творческие способности.

Выявлена высокая степень корреляции между суммами, вкладываемыми в обучение персонала, и общим успехом проекта, поэтому надо постоянно проводить обучение и переподготовку сотрудников. Любые авралы необходимо минимизировать. К авралам (как это на первый взгляд ни парадоксально) обычно приводит работа более 40 часов в неделю, что говорит о неверной организации труда и скрытых ошибках в организационной структуре.

Пример процесса «управление требованями»

Одна из первых работ при проектировании ПО — сбор и упорядочение требований к нему. Требование — это условие, которому должна удовлетворять система, или свойство, которым она должна обладать, чтобы удовлетворить потребность пользователя в решении некоторой задачи и удовлетворить требования контракта, стандарта или спецификации.

Спецификация требований к ПО является основным документом, который играет определяющую роль по отношению к другим элементам плана разработки ПО. Все требования, определенные в спецификации, делятся на функциональные и нефункциональные. Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. Тем самым функциональные требования определяют поведение системы в процессе обработки информации. Нефункциональные требования не определяют поведение системы, но описывают ее атрибуты или атрибуты системного окружения.

Применительно к программным системам предложена следующая классификация требований, которая получила название модели FURPS+, что соответствует первым буквам соответствующих категорий требований на английском языке:

• функциональные требования (Functionality);

• требования удобства использования (Usability);

• требования надежности (Reliability);

• требования производительности (Performance);

• требования возможности сопровождения (Supportability).

• При этом символом «+» обозначены дополнительные условия, к которым относятся:

• проектные ограничения;

• требования управления системой;

• требования к графическому интерфейсу пользователя;

• физические требования;

• юридические требования.

Центральное место среди указанных требований занимают функциональные, которые специфицируют особенности реализации отдельных бизнес-процессов моделируемой системы. В контексте моделей языка UML именно функциональные требования должны служить исходной информацией для построения диаграмм вариантов использования.

Требование не должно быть проектным решением. Способ реализации требования будет определен на стадии проектирования системы. Если требование является проектным решением, то такое требование должно быть отмечено как ограничение.

К требованиям не относятся способы управления проектом, планы, методы верификации, управления конфигурацией, тестовые процедуры и т.д.

Работа с требованиями порождает целый ряд проблем:

• требования не очевидны, приходят из разных источников, их трудно сформулировать словами из-за внутренней неоднозначности языка;

• требования разнообразны по типам и детальности, могут достигать огромного количества, которое трудно контролировать;

• требования разнообразны по значимости (обязательность, риск, важность, стабильность);

• требования связаны между собой и с другими проектными данными, изменяются в жизненном цикле ПО.

Изначально требования собираются в виде протоколов совещаний и интервью с заказчиками и пользователями, копий и оригиналов различных документов, отчетов существующей системы и массы других материалов. Потом их начинают упорядочивать и «очищать» от противоречий. Затем на их основе вырабатываются требования к компонентам системы — базам данных, программным и техническим средствам. При этом аналитику, проводящему обследование, приходится иметь дело с большим количеством неструктурированных, часто противоречивых требований и пожеланий, разбросанных по всевозможным соглашениям о намерениях, приложениям к договорам, протоколам рабочих совещаний, черновым материалам обследований. Без организованных усилий по регистрации и контролю за выполнением этих требований велик риск их «потерять». Кроме того, известно, что ошибки в требованиях - самые дорогостоящие и самые распространенные. Переделка ПО обычно занимает 40-50% бюджета проекта, при этом ошибки в требованиях отнимают наибольшую часть стоимости переделки ПО (>70%) и 30-40% общей стоимости бюджета проекта.

Наиболее распространенные методы проектирования ПО сосредоточены на моделировании требований с помощью различного рода диаграмм. Но в данном случае мы имеем в виду управление требованиями. Эти два понятия — моделирование и управление — не являются противоречивыми или несовместимыми.

В реальных проектах пользовательские требования зачастую должным образом не документируются; в свое оправдание разработчики говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не знают, что им нужно. Таким образом, обычно полагаются на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к системе. Это порождает одну главную проблему: невозможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования необходимо выполнить, а какие можно отложить на более позднее время? Структурные и объектно-ориентированные методы не дают ответа на этот вопрос, поскольку они предназначены в первую оче-редь для понимания и объяснения требований, а не для управления ими в динамике.

Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудности, поскольку сами требования и их приоритеты изменяются в течение проекта. Большинство крупных проектов включает сотни требований, а многие - даже тысячи (например, проект самолета Боинг-777, который называли мешком программ с крыльями, включал, по некоторым данным, около 300 000 требований). Кроме того, некоторые требования зависят от других требований, а некоторые в свою очередь порождают другие требования.

Все это подразумевает необходимость в методах и средствах для описания зависимостей между требованиями и управления большим количеством таких зависимостей. В решении данной проблемы могут частично помочь структурный анализ и объектно-ориентированный анализ, но эти методы традиционно игнорируют атрибуты требований, такие, как приоритет, стоимость, риск, план и разработчик, который занимается его реализацией. В результате проектным командам, испытывающим потребность в управлении требованиями, приходилось использовать доморощенные средства, базирующиеся на электронных таблицах, текстовых процессорах или наспех созданных приложениях, чтобы обеспечить хотя бы некоторую степень автоматизированной поддержки.

Управление требованиями (requirements management) представляет собой:

• систематический подход к выявлению, организации и документированию требований к системе;

• процесс, устанавливающий соглашение между заказчиками и разработчиками относительно изменения требований к системе, и обеспечивающий его выполнение.

Модель СММ характеризует деятельность по управлению требованиями следующим образом. Управление требованиями осуществляется для того, чтобы:

• достичь соглашения с заказчиком и пользователями о том, что система должна делать;

• улучшить понимание требований к системе со стороны разработчиков;

• определить границы системы;

• определить базис для планирования.

Понимание требований служит основой соглашения между заказчиком и командой разработчиков, которое является основным документом, определяющим все последующие действия. Формируется базовый уровень требований, на основе которого осуществляется управление разработкой ПО. Модель СММ предусматривает, чтобы все планы, графики и рабочие программные продукты разрабатывались и, если нужно, модифицировались в соответствии с требованиями, налагаемыми на ПО. Для осуществления данного процесса менеджеры проекта и заинтересованные лица (включая представителей заказчика и пользователей) должны документировать и пересматривать требования к ПО.

Например, в технологии Rational Unified Process определяются пять уровней зрелости процесса управления требованиями:

1. требования записаны в согласованном формате;

2. требования организованы, используются стандартные форматы и метаданные о требованиях, поддерживается контроль версий;

3. требования структурированы в соответствии со своими типами (функциональными и нефункциональными);

4. требования отслеживаются в соответствии с их типом;

5. требования интегрируются с процессами управления изменениями, моделирования, кодирования и т.д.

Чтобы соответствовать первому уровню, достаточно взять стандартный тестовый редактор или электронную таблицу для хранения требований; при этом принципы их использования разными группами команды разработки не стандартизованы. На втором уровне документы с описанием требований должны иметь согласованный формат, следовать определенной схеме нумерации и контроля версий. Уровень структурированных требований означает переход к созданию стандартных спецификаций с целым рядом атрибутов (приоритет требования, риск, стоимость и др.). Следующие уровни ставят задачу отслеживания зависимостей между различными требованиями, а также их влияния на другие модели в жизненном цикле ПО.

Чтобы добиться осуществления целей управления требованиями и соответствия модели СММ в области управления требованиями, необходимо выделить определенные ресурсы. Нужно обучить участников разработки деятельности по управлению требованиями. Обучение должно предусматривать изложение методов и стандартов, а также способствовать формированию понимания командой разработчиков особенностей предметной области и существующих в ней проблем. Помимо обучения, организация процесса управления требованиями предусматривает:

• организацию соответствующей инфраструктуры (ответственные исполнители, инструментальные средства, средства взаимодействия (интранет/интернет, электронная почта));

• определение источников возникновения и механизмов выявления требований;

• определение процедуры обсуждения требований и правил принятия решений по ним;

• определение механизмов регистрации и обработки изменений требований и принятия решений по ним.

В процессе работы с требованиями выделяются следующие этапы:

• определение типов требований и групп участников проекта, работающих с ними;

• первичный сбор требований, их классификация и занесение в базу данных требований;

• использование базы данных требований для управления проектом.

Требования, вносимые в базу данных, обладают следующим стандартным набором атрибутов, который может быть расширен при необходимости:

• приоритет (высокий, средний, низкий);

• статус (предложено, одобрено, утверждено, реализовано, верифицировано);

• стоимость (высокая, средняя, низкая или числовое значение);

• сложность реализации (высокая, средняя, низкая);

• стабильность (высокая, средняя, низкая);

• исполнитель.

Еще одним важным аспектом управления требованиями является трассировка. Трассировка требований — это установка связей требований с другими требованиями или проектными решениями. Цель трассировки требований:

• убедиться, что все требования к системе выполнены в процессе реализации;

• убедиться, что ПО делает только то, что предполагалось;

• облегчить внесение изменений в ПО (управление изменениями).

С помощью трассировки требований можно анализировать воздействие изменения до того, как оно произведено, а также определять, на какие компоненты повлияет внесение изменения. Все принятые изменения полностью отслеживаются. Изменения считаются неотъемлемой составной частью действий по разработке ПО. Вместо «замороженных» спецификаций формируется стабильный базовый уровень требований, которые тщательно изучены, документированы и контролируются соответствующими системами, обеспечивающими управление изменениями.

В рамках процесса управления требованиями необходимо иметь возможность расстановки приоритетов требований и их изменения. Один из наиболее полезных способов расстановки приоритетов предлагает учитывать два измерения: важность и срочность, которые оцениваются по двоичной шкале. В результате получаются четыре комбинации для определения приоритетов:

• требования с высоким приоритетом — важные (пользователям нужны данные функции) и срочные (они необходимы в данной версии). Некоторые требования приходится включать в эту категорию согласно контрактным или юридическим обязательствам;

• требования со средним приоритетом - важные (пользователям нужны данные функции), но не срочные (они могут подождать до следующей версии);

• требования с низким приоритетом — не важные (пользователи при необходимости могут обойтись без этих функций), и не срочные (они могут ждать сколько угодно);

• требования, кажущиеся срочными, но в действительности не являющиеся важными, вообще не заслуживают внимания и не приносят никакой ценности.

При такой расстановке приоритетов в проекте стратегия его выполнения будет заключаться в следующем: в первую очередь сосредоточиться на требованиях с высоким приоритетом, затем сосредоточиться на требованиях со средним приоритетом, и в последнюю очередь, если останется время, заняться требованиями с низким приоритетом. Если не следовать такой стратегии с самого начала проекта, то к концу он окажется в кризисной ситуации. Дополнительными факторами ранжирования требований по приоритетам являются:

• существенное влияние на архитектуру системы;

• рискованные, сложные для реализации или срочные функции;

• применение новой, не апробированной технологии;

• значимость в экономических процессах.

Управление требованиями относится к процессам, техническая поддержка которых не требует больших финансовых затрат, но они способны ощутимо повысить качество создаваемой системы.

Пример процесса «управление конфигурацией ПО»

Управление конфигурацией ПО (см. подразд. 1.2.2) является одним из наиболее важных вспомогательных процессов жизненного цикла ПО. Цель управления конфигурацией - обеспечить управляемость и контролируемость процессов разработки и сопровождения ПО. Для этого необходима точная и достоверная информация о состоянии ПО и его компонентов в каждый момент времени, а также обо всех предполагаемых и выполненных в процессе сопровождения изменениях.

Изменения, вносимые в ПО, — это некоторые события, которые имеют автора, назначение, содержание и время исполнения. Они могут быть независимыми, согласованными (взаимосвязанными) или альтернативными (взаимоисключающими). Изменения разрабатываются и реализуются в разное время, вследствие чего корректность группы изменений может зависеть от синхронности их внесения в различные компоненты определенной версии ПО.

Изменения разделяются на следующие группы:

• срочные изменения, которые должны не только быть внесены в очередную версию ПО, но и сообщены пользователям для оперативной модификации ПО до внедрения официальной версии;

• изменения, которые целесообразно внести в очередную версию с учетом затрат на их реализацию ПО;

• изменения, которые требуют дополнительного анализа целесообразности и эффективности их реализации, в последующих версиях и могут не внедряться в очередную версию ПО;

• изменения, которые не оправдывают затрат на их внесение или практически не влияют на качество и эффективность ПО, и поэтому не подлежат реализации. Изменение конфигурации ПО должно планироваться и предусматривать в плане действия с четкими разделами:

• почему и с какой целью производится модификация ПО;

• кто выполняет и санкционирует проведение изменений;

• какие действия и процедуры должны быть выполнены для реализации изменений;

• когда по срокам и в координации с какими другими процедурами следует реализовать определенную модификацию ПО;

• как и с использованием каких средств и ресурсов должны быть выполнены запланированные изменения ПО.

Все проанализированные изменения регистрируются. Для принятых к внедрению изменений разрабатывается план доработок ПО и определяется ответственный за каждую модификацию ПО.

В процессе управления конфигурацией необходимо построить и использовать компактные и наглядные схемы однозначной иерархической идентификации:

• объектов - модулей и компонентов ПО, подвергающихся модификации;

• проводимых изменений (с целью отслеживания истории модификации компонентов любого уровня);

• специалистов, участвующих в управлении конфигурацией, и их прав на доступ к определенным компонентам ПО на конкретных стадиях разработки, реализации и утверждения изменений.

• Для решения задач управления конфигурацией и изменениями (в современных технологиях эти процессы объединяются в один) применяются методы и средства, обеспечивающие идентификацию состояния компонентов, учет номенклатуры всех компонентов и модификаций системы в целом, контроль за вносимыми изменениями в компоненты, структуру системы и ее функции, а также координированное управление развитием функций и улучшением характеристик системы.

Наиболее развитые современные средства управления кон-фигурацией и изменениями ПО обладают следующими возможностями:

• хранение в БД управления конфигурацией полных хронологий версий каждого объекта, созданного или измененного в процессе разработки системы (к ним относятся исходный программный код, библиотеки, исполняемые программы, модели, документация, тесты, web-страницы и каталоги);

• поддержка географически удаленных групп разработчиков;

• контроль изменений, вносимых во все объекты системы;

• сборка версий ПО из компонентов проекта.

Средства контроля версий могут использоваться в рабочих группах. Система блокировок, реализованная в них, позволяет предотвратить одновременное внесение изменений в один и тот же объект, давая разработчикам в то же время возможность работать с собственными версиями общего объекта с разрешением конфликтов между ними.

Средства контроля изменений обычно используются в комплексе со средствами управления требованиями. Поступающее требование или замечание проходит четыре этапа обработки:

• регистрация — внесение замечания в базу данных;

• распределение — назначение ответственного исполнителя и сроков исполнения;

• исполнение — устранение замечания, которое, в свою очередь может вызвать дополнительные замечания или требования на дополнительные работы;

• приемка — приемка работ и снятие их с контроля или направление на доработку.

• регистрация — внесение замечания в базу данных;

• распределение — назначение ответственного исполнителя и сроков исполнения;

• исполнение — устранение замечания, которое, в свою очередь может вызвать дополнительные замечания или требования на дополнительные работы;

• приемка — приемка работ и снятие их с контроля или направление на доработку.

Отчетные возможности включают множество разновидностей графиков и диаграмм, отражающих состояние проекта, срезы по различным компонентам проекта, разработчикам и тестиров-щикам. С их помощью можно наглядно показать состояние работы над проектом и динамику ее развития.

Наличие средств управления конфигурацией и изменениями означает обеспечение целостности проекта и контроля за его состоянием, что является жизненно важным в условиях разобщенности разработчиков и временной протяженности крупного проекта. Это предполагает наличие единой технологической среды создания и сопровождения, которая должна обеспечиваться программно-технологическими интерфейсами между отдельными инструментальными средствами.

! Следует запомнить

1. Разработка больших проектов невозможна без совокупности нормативно-методических документов, регламентирующих различные аспекты процессов деятельности разработчиков.

2. Одним из базовых понятий программной инженерии является понятие жизненного цикла программного обеспечения (ЖЦ ПО). Жизненный цикл программного обеспечения определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

3. Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наиболее распространенными моделями являются каскадная и итерационная.

4. Зрелость процессов ЖЦПО — это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации.

Основные понятия

Нормативно-методическое обеспечение, жизненный цикл программного обеспечения, процессы жизненного цикла, модель ЖЦ ПО, стадия процесса создания ПО, каскадная модель, итерационная модель, зрелость процессов.

Вопросы для самоконтроля

1. Что такое жизненный цикл программного обеспечения?

2. Чем регламентируется ЖЦ ПО?

3. Какие группы процессов входят в состав ЖЦ ПО и какие процессы входят в состав каждой группы?

4. Какие из процессов, по вашему мнению, наиболее часто используются в реальных проектах, какие в меньшей степени и почему?

5. Какие стадии входят в процесс создания ПО?

6. Каково соотношение между стадиями и процессами ЖЦ ПО?

7. Каковы принципиальные особенности каскадной модели?

8. В чем заключаются преимущества и недостатки каскадной модели?

9. Каковы принципиальные особенности итерационной модели?

10. В чем состоят преимущества и недостатки итерационной модели?

11. Каким образом можно добиться повышения уровня зрелости процессов создания ПО?

12. Какую роль в повышении уровня зрелости играют процессы управления требованиями и управления конфигурацией ПО?